As information technologies develop continuously, more data needs to be stored and processed. During construction of a data center, increasingly strict requirements on reliability and disaster recovery need to be met, and resource utilization also needs to be improved. Therefore, an active-active data center solution emerges. Same hosts and storage systems established at two locations are interconnected by using a dedicated network. Upper-layer applications and servers form a two-location cluster, and a two-location cluster is also formed in terms of storage, so as to implement fail-over and load balancing of multiple layers: application, network, and storage, and use less investment to implement zero data loss with close-to-zero service interruption time.
An active-active data center has data volumes mirroring each other at two locations. The data volumes present a same identifier and attribute to the upper-layer applications and servers, and may be considered as an “active-active mirror volume” that is logically a whole but whose two pieces of mirror data are separately at the two locations. A snapshot may be understood as a copy of a data set, and the copy includes an image of corresponding data at a particular time point (a start time point of copying), or the snapshot may be understood as a duplicate of a data set at a time point. An active-active snapshot is a snapshot of the active-active mirror volume, and is actually snapshots of a pair of mirrors forming in the active-active mirror volume. Data in the snapshots is completely the same, so that the active-active mirror volume may roll back to a state of a time point (for example, a snapshot rollback of the active-active mirror volume means that data at the two locations needs to roll back to a same state). Because data of the active-active mirror volume at the two locations is concurrent and the data changes at any time, snapshots finally taken at the two locations may be inconsistent without a good cooperation mechanism.
In prior-art solutions, input/output (I/O) interfaces of multiple sites are usually simultaneously blocked or suspended, and when there is no new change in data, snapshots are taken together. However, most active-active snapshots are in a long-distance and cross-site scenario, I/O interfaces at two locations are concurrent, and each write request needs to be synchronized to a remote end. Therefore, during a large amount of concurrent data, two sites wait each other and suspend I/O interfaces, and completing taking snapshots needs a relatively long latency. Consequently, an upper application service is affected, even a pause occurs or temporarily no response is received, and a snapshot rate is low.